The present invention relates generally to event-processing rules. In particular, the present invention relates to providing event-processing rules in an event-processing environment.
Organizations may wish to offer their customers the ability to write their own individual event-processing rules, which can be applied during run time. However, when an organization has a large number of customers, this can result in a requirement for hundreds of thousands of individual rules. Managing large amounts of rules can be difficult to manage effectively and can also carry significant performance penalties.
For example, consider the case where a bank customer wishes to be notified whenever a large debit (>£200) arrives and their account is currently overdrawn. The customer may wish to receive an SMS message if the account is more than £500 overdrawn and an email if it is up to £500 overdrawn. The rule for the email part of this scenario may be written as:
if (−£500<balance<£0) AND transaction>£200 then send notification (email) to customer.
There are two existing options to represent this kind of information for hundreds of thousands customers. The first option is for every customer to have his or her own individual rules, which results in hundreds of thousands of rules. The second option is for the rule to be parameterized in the form of:if −A<balance<B and transaction>C. 
In this case there may be one rule and the values of A, B and C may simply be stored for each customer. This solution may work for a limited number of parameters and operands. However, if true flexibility of operators is allowed (e.g. <, >, =, !=, >=, <=, <>) and any number of logical expressions are allowed to be concatenated, then it will still require thousands of rules or parameterized expressions to be written to cover all possible cases. This is made worse if further parameters are introduced.